Modeling languages may be used as meta-languages to describe and execute underlying processes, such as business processes. For example, process modeling languages allow an enterprise to describe tasks of a process, and to automate performance of those tasks in a desired order to achieve a desired result. For instance, the enterprise may implement a number of business software applications, and process modeling may allow coordination of functionalities of these applications, including communications (e.g., messages) between the applications, to achieve a desired result. Further, such process modeling generally relies on a language that is common to, and/or interoperable with, many types of software applications and/or development platforms. As a result, for example, process modeling may be used to provide integration of business applications both within and across enterprise organizations.
Such modeling languages allow a flow of activities to be graphically captured and executed, thereby enabling resources responsible for the activities to be coordinated efficiently and effectively. The flow of work in a process may be captured through routing (e.g., control flow) constructs, which allow the tasks in the process to be arranged into the required execution order through, for example, sequencing, choices (e.g., decision points allowing alternative branches), parallelism (e.g., tasks running in different branches which execute concurrently), iteration (e.g., looping in branches) and synchronization (e.g., the coming together of different branches).
Within the framework or infrastructure provided by such modeling languages and process execution environments, many different applications may be implemented. For example, business applications, such as customer relationship management, supply chain management, or inventory control applications may be implemented, at least in part, by using such process automation.
In many such applications, confidential data may need to be stored, exchanged, or accessed. Consequently, it may be advantageous or required to have a sufficient amount of security that may be provided in association with such data. For example, some conventional approaches have implemented security mechanisms that are external to the processes and their execution environment(s) themselves, and that enforce security requirements in a non-intrusive manner, e.g., by intercepting inputs to, or outputs of, the processes. Such approaches, however, may be limited in their ability to provide a range or extent of in depth security mechanisms.